In modern user terminals for communication, there are typically multiple options available for communication and usage of services in a communication network. For example, a user terminal may be capable of supporting several different types of communication such as voice calls, video telephony, messaging based on Short Message Service (SMS) and Multimedia Message Service (MMS), text chats, file sharing, video sharing, online games, and also different encoding schemes and protocols, to mention a few illustrative examples. In this description, the term “capabilities” basically refers to such communication types, encoding schemes and protocols.
A network architecture called “IP Multimedia Subsystem” (IMS) has been developed to enable such differentiated services and sessions for user terminals connected to different access networks. The signalling protocol “ Session Initiation Protocol” (SIP) can further be used for initiating and controlling communication sessions between different entities, as controlled by specific session control nodes in the IMS network, sometimes referred to as Call Session Control Function (CSCF) nodes. IMS also allows a user to have more than one terminal that can be addressed by the same identity, typically a telephone number.
There is thus a mixture of different user terminals in use today, having more or less differentiated capabilities, and when two user terminals shall execute some communication with each other, it is a common practice that they compare their capabilities first in order to know which type of communication is available for these two particular terminals. The communication type to use must be supported by both terminals, otherwise it cannot be used.
In the following description, the term “user terminal” is used to represent any terminal, user equipment, device, etc. which is capable of communication with an opposite entity such as another user terminal over a communications network. Some non-limiting examples of user terminals that can be used in this context include mobile phones, smartphones, laptop computers, tablets, television units, media players, and game consoles. Each of these terminal categories includes in turn a myriad of different brands and models with different functions and communication possibilities.
One existing mechanism for exchanging capabilities between entities is the so-called “SIP Options” method, which is schematically illustrated in FIG. 1. In this example, an originating user terminal 100 sends a SIP Options message towards a terminating user terminal 102, in an action 1:1, which message is routed over a session control node 106 in a network 104 for communication services. For example, the network 104 may be an IMS network and the session control node 106 may be a CSCF node comprised therein. The SIP Options message may be triggered in terminal 100 when a user selects a contact of terminal 102 in preparation of a forthcoming session.
In particular, the SIP Options message from terminal 100 may include the capabilities of terminal 100, e.g. presented basically in the form of a list or record indicating which communication types the terminal 100 is capable of using. The opposite user terminal 102 conventionally responds by returning a so-called “200 OK” message to terminal 100, in an action 1:2, which typically always includes the capabilities of terminal 102 indicating which communication types the terminal 102 is capable of using. Thereby, the capabilities of the terminals 100, 102 have been exchanged and each terminal can determine which communication types are possible to use, i.e. those supported by both terminals. The capabilities of either terminal are thus exposed in this way at the opposite side and the available communication options can also be displayed on the terminals 100, 102, e.g. by showing or lightening corresponding icons or the like on the screen, such that their respective users can easily see which options are available before selecting and activating a communication type to use.
GSM Association (GSMA) has selected such a capability query mechanism that allows a user of a user terminal with a Rich Communication Suite (RCS) client, to query another user terminal for a complete set of service capabilities. This allows an RCS subscriber to add a phone number into his/her contact book whereby the user terminal automatically queries the capabilities of the terminal belonging to the party associated with said phone number.
Another known mechanism, schematically illustrated in FIG. 2, is to exchange capabilities between two user terminals 200 and 202 by means of a presence service. In this example, the capabilities of terminal 202 are first published in a presence server 204, as illustrated in an action 2:1. The other terminal 200 may do the same, although not shown here for simplicity. The terminal 200 may subscribe to the capability information of terminal 202 and is therefore able to obtain the published capabilities of terminal 202, in another action 2:2, e.g. by fetching them from the presence server 204 or by receiving a notification therefrom. Using common presence terminology, terminal 202 acts as a “presentity” while terminal 200 acts as a “watcher”, and vice versa is of course also possible.
In this case, it is not necessary to exchange capabilities in specific request and response messages between the terminals 200, 202, as in the above SIP Option method. Once retrieved, the capabilities of terminal 202 are known and used by terminal 200 to determine which types of communication are possible to use, and corresponding icons or the like may be displayed on the screen of terminal 200 indicating to its user which options are available. The user of terminal 200 can thus select and activate an available communication type, and a session request or the like is then issued to terminal 202 over a session control node 206, in an action 2:3. Terminal 202 will then respond accordingly to the session request in another shown action 2:4.
However, there are some drawbacks associated with the above procedures. A user may not be willing to expose his/her terminal(s) for starting, e.g., a video call or a text chat with anybody, depending on the current situation and/or depending on who is calling which could be a totally unknown person. One possibility often used to avoid unwanted calls is to block the terminal altogether from incoming calls, which can also be done selectively e.g. using so-called “black lists” or “white lists”. Still, when using the SIP Options method of FIG. 1, the capabilities of one or more terminals associated with an identity such as a called number are automatically exposed at the opposite calling terminal in a way that cannot be controlled, which can be perceived by the called user as an intrusion of privacy. It is possible for an illicit party to gain knowledge of the characteristics and current state of a user's terminals and their locations simply by making capability requests according to the SIP Option method, e.g. for planning some malicious attack.
Even if the presence method of FIG. 2 provides some flexibility in that the terminal user can select which capabilities to expose by publication, this method is deemed somewhat taxing and costly by requiring establishment of a presence service. Further, the published capability information may be out of date or misleading, e.g. if the capabilities have not been updated or properly published in the presence server by the user as required, or if the terminal is currently in a situation which is not suitable for some of the published communication types such as when a mobile terminal is present in an area with very limited bandwidth, or when the user's terminal is simply turned off or otherwise unavailable for one or more communication types.